home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98a.txt / 000065_icon-group-sender _Thu Feb 26 13:58:22 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.7/8.8.7) with SMTP id NAA08485
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Thu, 26 Feb 1998 13:58:21 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA00098; Thu, 26 Feb 1998 13:58:21 -0700
  7. Message-Id: <34F585F0.1AFC@gte.net>
  8. Date: Thu, 26 Feb 1998 09:10:40 -0600
  9. From: Mark Evans <evans@gte.net>
  10. Reply-To: evans@gte.net
  11. Organization: None
  12. X-Mailer: Mozilla 3.01 (Win95; I)
  13. Mime-Version: 1.0
  14. To: icon-group@optima.CS.Arizona.EDU
  15. Cc: evans@gte.net
  16. Subject: Re: Translation into C
  17. References: <199802251930.NAA16169@axp.cmpu.net>
  18. Content-Type: text/plain; charset=us-ascii
  19. Content-Transfer-Encoding: 7bit
  20. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  21. Status: RO
  22. Content-Length: 3434
  23.  
  24. gep2@computek.net wrote:
  25. > 
  26. > > Mark Evans suggested that the reason one might want an Icon to C
  27. > translator is that the resulting program will execute faster because it
  28. > doesn't need to be interpreted.  But I wonder how much difference that
  29. > would really make.  If the C program spends most of its time calling
  30. > library routines, then I wouldn't expect much difference at all.
  31. > 
  32. > Right.
  33. >
  34.  
  35. I don't follow the logic here.  Even compiled C programs spend most of
  36. their time inside libraries (system, numerical, string, file).  I
  37. certainly don't want to rewrite the StdCLib.
  38.  
  39. > > Does anyone have statistics that might answer this question?
  40. > 
  41. > I think that statistics for different implementations will vary all over the
  42. > place... I'd comment though that generally the overhead of an interpreter is
  43. > less (and the advantages are more) for higher-level languages than for
  44. > lower-level ones, for exactly the reason you yourself suggested above.
  45. > 
  46.  
  47. I have some anecdotal statistics of my own.  I have used several
  48. interpreted languages related to numerical analysis; let's take four of
  49. them, Mathematica, MATLAB, O-Matrix, and LabVIEW.  In principle, all of
  50. them are interpreted except LabVIEW, which claims to be "compiled."
  51.  
  52. I've used Mathematica more than any of them and it is closest in nature
  53. to Icon.  It is very high-level.  The usual case is that I prototype an
  54. algorithm in MMA and then port it to C.  The resulting speedup is
  55. usually larger than 10x, sometimes 20x to 50x.  The example I am
  56. thinking of is 2D image convolution.  I know how to code well in MMA so
  57. I know it's not my skill involved here.  MMA has dynamic typing and
  58. other goodies similar to Icon.  In fact the two are fairly close in many
  59. respects.  It's very easy to create data structures in either language.
  60.  
  61. MATLAB - One of my clients recently asked a local robotics research
  62. outfit (ARRI) to build a simulation of their hydraulic system.  They
  63. used MATLAB and then switched to C for speed.  They switched on their
  64. own initiative because MATLAB was too slow.  The speedup was on the
  65. order of 40x (forty minutes down to one).  This was for a time-domain
  66. simulation of a relatively simple hydraulic strut invovling pressure,
  67. temperature, and bulk modulus changes to figure out the spring and
  68. damping forces.  Several nonlinear dynamical equations involved.
  69.  
  70. O-Matrix - an unusual case (http://www.omatrix.com).  This is
  71. essentially a MATLAB clone.  What make it interesting is that the
  72. company claims a 5x speed improvement over MATLAB, not by eliminating
  73. interpretation, but BY WRITING THE LIBRARY ROUTINES EFFICIENTLY.  I
  74. inquired specifically about this some while ago and the answer came back
  75. that it was basically their hand-tuned assembly-language libraries that
  76. gave them the edge over MATLAB's plain Jane C libraries.  So yes,
  77. library implementation can make a huge difference.
  78.  
  79. LabVIEW - Very interesting indeed.  The vendor uses a kind of
  80. compilation in LabVIEW of a nature that they say is "as fast as C."   It
  81. may be so for some simple Whetstone types of benchmarks, but in general
  82. I have done algorithms both ways, and LabVIEW's speed doesn't hold a
  83. candle to C.  I would estimate the slowdown again at 10x-20x or
  84. thereabouts.  I have used LabVIEW extensively and know how to code it
  85. well.
  86.  
  87. All of the above indicate to me that no interpreted system in existence
  88. has yet come close to C even though they claim to have done so.
  89.  
  90. Mark
  91.  
  92.